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Abstract 

This  paper  describes  a  class  of  formal  analysis 
called  consistency  checking  that  mechanically  checks 
requirements  specifications,  expressed  in  the  SCR  tab¬ 
ular  notation,  for  application-independent  properties. 
Properties  include  domain  coverage,  type  correctness, 
and  determinism.  As  background,  the  SCR  notation 
for  specifying  requirements  is  reviewed.  A  formal  re¬ 
quirements  model  describing  the  meaning  of  the  SCR 
notation  is  summarized,  and  consistency  checks  de¬ 
rived  from  the  formal  model  are  described.  The  re¬ 
sults  of  experiments  to  evaluate  the  utility  of  auto¬ 
mated  consistency  checking  are  presented.  Where  con¬ 
sistency  checking  of  requirements  fits  in  the  software 
development  process  is  discussed. 

1  Introduction 

A  recent  study  of  industrial  application  of  formal 
methods  concludes  that  formal  methods,  including 
those  for  specifying  and  analyzing  requirements,  are 
“beginning  to  be  used  seriously  and  successfully  by 
industry.  .  .to  develop  systems  of  significant  scale  and 
importance”  [5].  Included  in  the  study  is  the  Soft¬ 
ware  Cost  Reduction  (SCR)  method  for  specifying  re¬ 
quirements.  Introduced  more  than  a  decade  ago  to 
describe  the  functional  requirements  of  software  un¬ 
ambiguously  and  concisely  [13,  14],  the  SCR  method 
has  been  extended  recently  to  describe  system,  rather 
than  simply  software,  requirements  and  to  incorpo¬ 
rate  techniques  for  representing  nonfunctional  require¬ 
ments,  such  as  timing  and  precision  [17,  21,  22]. 

Designed  originally  for  use  by  engineers,  the  SCR 
method  has  been  successfully  applied  to  a  variety  of 
practical  systems.  These  include  avionic  systems,  such 
as  the  A- 7  Operational  Flight  Program  (OFP)  [13,  1]; 
a  submarine  communications  system  [12];  and  safety- 
critical  components  of  two  nuclear  power  plants,  the 
Darlington  plant  in  Canada  [22]  and  a  second  plant  in 
Belgium  [4].  Recently,  a  consortium  of  aerospace  com¬ 
panies  has  developed  a  version  of  the  SCR  method, 
called  CoRE,  to  capture  and  document  the  require¬ 
ments  of  avionics  and  space  applications  [7,  8]. 

While  the  above  applications  of  SCR  rely  on  man¬ 
ual  techniques,  effective  use  of  the  method  in  indus¬ 
trial  settings  will  require  powerful  and  robust  tool 
support.  As  observed  in  the  formal  methods  study 
[5],  tool  support  for  formal  methods,  though  currently 
weak  and  impoverished,  is  “necessary  for  the  full  in¬ 
dustrialization  process.  .  .  and  needs  to  be  an  integral 
part  of  a  broader  software  development  tool  suite.” 
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Further,  one  of  the  original  developers  of  the  SCR 
method  and  a  leader  in  the  certification  of  the  Dar¬ 
lington  software  cites  the  “need  for  tool  support  to 
make  the  process  practical”  [18]. 

An  important  question  is  what  form  tool  support 
should  take.  To  answer  this  question,  our  group  is 
developing  a  prototype  toolset  for  constructing  and 
analyzing  SCR-style  requirements  specifications.  The 
toolset  includes  a  specification  editor  for  creating  and 
editing  formal  requirements  specifications,  a  simula¬ 
tor  for  symbolically  executing  the  specifications,  and 
formal  analysis  tools  for  testing  the  specifications  for 
selected  properties. 

Three  classes  of  formal  analysis  can  be  applied  to 
requirements  specifications.  One  class  called  consis¬ 
tency  checking,  the  subject  of  this  paper,  tests  that 
requirements  specifications  satisfy  a  formal  require¬ 
ments  model.  The  requirements  model  describes  the 
set  of  properties  that  all  requirements  specifications 
must  satisfy.  Hence,  the  properties  tested  by  the  con¬ 
sistency  checker  are  independent  of  a  particular  appli¬ 
cation. 

The  other  two  classes  of  formal  analysis  require  the 
successful  completion  of  the  first:  both  depend  on  a 
consistent  (and  complete)  requirements  specification. 
The  second  class  checks  the  requirements  specification 
for  application  properties.  These  properties  include 
safety  properties,  which  prevent  unplanned  events  that 
result  in  death,  injury,  illness,  or  damage  to  property; 
timing  properties,  which  require  the  system  to  produce 
results  within  specified  time  intervals  (see,  e.g.,  [9]); 
and  security  properties,  which  prevent  the  unautho¬ 
rized  disclosure,  modification,  and  withholding  of  sen¬ 
sitive  information  (see,  e.g.,  [15]).  Given  a  system  re¬ 
quirements  specification  and  another  system  descrip¬ 
tion  (such  as  a  software  design  or  source  code),  the 
third  class  of  formal  analysis  checks  that  the  system 
description  satisfies  the  requirements  specification. 

The  properties  that  consistency  checking  tests  are 
usually  quite  simple.  For  example,  given  a  require¬ 
ments  specification  that  includes  a  total  function  F, 
the  consistency  checker  tests  that  F  is  indeed  total 
(i.e. ,  defined  everywhere  in  F’s  domain).  While  sim¬ 
ple,  the  number  of  times  such  properties  need  to  be 
checked  in  practical  requirements  specifications  can 
become  very  large,  and  thus  reviewers  must  spend 
considerable  time  and  effort  verifying  that  the  spec¬ 
ifications  have  the  properties.  In  fact,  in  the  certifi¬ 
cation  of  the  Darlington  plant,  Parnas  has  observed 
that  the  “reviewers  spent  too  much  of  their  time  and 
energy  checking  for  simple,  application-independent 
properties”  (such  as  the  ones  we  describe  in  this  pa¬ 
per)  which  distracted  them  from  the  “more  difficult, 
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safety-relevant,  issues”  [18].  Tools  that  automatically 
perform  such  checks  can  save  reviewers  considerable 
time  and  effort,  liberating  them  to  do  more  creative 
work. 

An  industrial-strength  formal  method  should  have 
a  formal  (that  is,  mathematical)  foundation  and 
should  be  usable  by  engineers,  scalable,  and  cost- 
effective.  Automated  consistency  checking  as  de¬ 
scribed  in  this  paper  is  an  important  step  in  develop¬ 
ing  such  a  method  for  requirements  specification.  It 
has  a  formal  foundation,  namely,  our  formal  require¬ 
ments  model  [10].  It  is  easy  to  use:  after  developing 
a  requirements  specification  in  the  SCR  notation,  the 
engineer  invokes  the  consistency  checker  to  find  incon¬ 
sistencies  automatically.  It  scales  up  to  handle  prac¬ 
tical  applications:  in  two  experiments,  our  automated 
consistency  checker  found  significant  errors  in  the  re¬ 
quirements  specification  of  a  medium-size  Navy  ap¬ 
plication.  These  errors  were  detected  even  though  the 
specification  had  previously  undergone  comprehensive 
checks  by  two  independent  review  teams.  These  re¬ 
sults  and  the  high  cost,  of  the  Darlington  certification 
effort.,  wIh.iv  such  checks  were  done  by  hand,  suggest, 
that  automated  consistency  checking  is  cost-effective. 
Finally,  automated  consistency  checking  is  an  impor¬ 
tant.  first,  step  in  formal  analysis  of  requirements  spec¬ 
ifications,  since,  as  indicated  above,  other  classes  of 
formal  analysis  require  a.  consistent,  specification. 

Although  earlier  requirements  models,  in  partic¬ 
ular,  Faulk’s  automaton  model  [6],  Pa.rna.s’  Four- 
Variable  Model  [17],  and  the  model  underlying  van 
Schouwen’s  specification  [21,  22],  define  some  aspects 
of  the  SCR  notation,  these  models  are  too  abstract, 
to  provide  a.  formal  basis  for  our  tools.  To  provide  a. 
precise  and  detailed  semantics  for  the  SCR  notation, 
our  requirements  model  represents  the  system  to  be 
built,  as  a.  state  automaton  and  describes  the  moni¬ 
tored  and  controlled  variables,  conditions,  events,  and 
other  constructs  that,  make  up  an  SCR  specification 
in  terms  of  that,  automaton.  This  automaton  model, 
an  extension  of  Faulk’s  and  a.  special  case  of  the  other 
two  models,  provides  the  formal  basis  for  our  auto¬ 
mated  consistency  checker  as  well  as  our  other  tools, 
in  particular,  the  specification  editor,  the  simulator, 
and  a.  verifier  that,  checks  the  specifications  for  appli¬ 
cation  properties  (the  second  class  of  formal  analysis 
described  above). 

After  reviewing  the  SCR  method  for  specifying  re¬ 
quirements,  this  paper  introduces  our  formal  require¬ 
ments  model,  describes  consistency  checks  based  on 
the  model,  presents  the  results  of  experiments  we  con¬ 
ducted  to  determine  the  utility  of  automated  consis¬ 
tency  checking,  and  discusses  where  consistency  check¬ 
ing  fits  in  the  software  development,  process.  The  con¬ 
tributions  of  this  paper  are  its  introduction  and  for¬ 
mal  definition  of  a.  class  of  analysis,  namely,  consis¬ 
tency  checking,  for  detecting  application-independent, 
errors  in  system  and  software  requirements  specifica¬ 
tions  and  the  evidence  it.  provides  that,  softwa.ntftools 
for  automated  consistency  checking  are  useful  and 
cost-effective. 


Figure  1:  Four  Variable  Model. 

2  Background:  SCR  Method 

The  purpose  of  a.  requirements  document,  is  to  de¬ 
scribe  all  acceptable  system  implementations  [12].  To 
minimize  implementation  bias,  a.  requirements  docu¬ 
ment.  should  specify  only  the  externally  visible  behav¬ 
ior  required  of  the  system.  To  achieve  this,  Pa.rna.s  has 
introduced  the  Four  Variable  Model,  a.  st.a.nda.rda.rized 
model  of  embedded  system  behavior  that,  describes  the 
required  system  functions,  timing,  and  precision  [17]. 
This  section  reviews  the  constructs  and  tabular  nota¬ 
tion  in  SCR  requirements  specifications  in  terms  of  the 
Four  Variable  Model.  Because  our  initial  requirements 
model  emphasizes  the  system’s  functions,  the  discus¬ 
sion  focuses  on  aspects  of  the  Four  Variable  Model 
that,  describe  functional  behavior. 

SCR  Constructs.  The  Four  Variable  Model,  illus¬ 
trated  in  Figure  1,  represents  requirements  as  a.  set.  of 
mathematical  relations  on  four  sets  of  variables  called 
monitored,  controlled,  input.,  and  output..  A  mon¬ 
itored  variable  represents  an  environmental  quantity 
that  influences  system  behavior,  a.  controlled  variable 
an  environmental  quantity  the  system  controls.  A 
black  box  specification  of  required  behavior  is  given 
as  two  relations  (REQ  and  NAT)  from  the  monitored 
quantities  to  the  controlled  quantities  (not.  inputs  to 
outputs).  NAT  defines  the  set  of  possible  values;  it. 
captures  any  constraints  on  behavior,  such  as  those 
imposed  by  physical  laws.  REQ  defines  the  additional 
constraints  imposed  by  the  system  to  be  built..  It.  de¬ 
scribes  the  required  system  behavior  by  defining  the 
relation  the  system  must,  maintain  between  the  moni¬ 
tored  and  the  controlled  quantities. 

Inputs  and  outputs  are.  treated  as  resources.  In¬ 
puts  are  resources  available  to  the  system  to  compute 
the  monitored  quantities.  The  relation  IN  defines  the 
mapping  from  the  monitored  quantities  to  the  inputs. 
Similarly,  the  relation  OUT  defines  the  mapping  from 
the  outputs  to  the  controlled  quantities.  The  use  of 
monitored  and  controlled  quantities  to  define  required 
behavior,  rather  than  inputs  and  outputs,  keeps  the 
specification  in  the  problem  domain  and  allows  a.  sim¬ 
pler  specification.  Below,  we  refer  to  monitored  vari¬ 
ables  and  inputs  as  input  variables ,  controlled  vari¬ 
ables  and  outputs  as  output  variables. 

Four  more  constructs,  all  introduced  in  the  A- 7  re¬ 
quirements  document.  [13],  are  useful  for  specifying 
systems  using  the  Four  Variable  Model.  These  are 
modes,  terms,  conditions,  and  events.  A  mode  class  is 
a.  state  machine,  whose  states  are  called  system  modes 
(or  simply  modes)  and  whose  transitions  are  triggered 
by  events.  Complex  systems  are  defined  by  more  than 
one  mode  class,  operating  in  parallel.  A  term  is  any 
function  of  input,  variables,  modes,  or  other  terms.  A 
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Figure  2:  Requirements  Spec,  for  Safety  Injection. 

condition  is  a  predicate  about  the  system  state.  An 
event  occurs  when  any  system  entity  (that  is,  an  input 
or  output  variable,  mode,  or  term)  changes  value.  A 
special  event,  called  an  input  event ,  occurs  when  an 
input  variable  changes  value.  Another  special  event, 
called  a  conditioned  event,  occurs  if  an  event  occurs 
when  a  specified  condition  is  true. 

To  illustrate  the  SCR  constructs,  we  consider  a  sim¬ 
plified  version  of  the  control  system  for  safety  injec¬ 
tion  described  in  [4] .  The  system  uses  three  sensors  to 
monitor  water  pressure  and  adds  coolant  to  the  reac¬ 
tor  core  when  the  pressure  falls  below  some  threshold. 
The  system  operator  blocks  safety  injection  by  turn¬ 
ing  on  a  “Block”  switch  and  resets  the  system  after 
blockage  by  turning  on  a  “Reset”  switch.  Figure  2 
shows  how  SCR  constructs  could  be  used  to  specify 
the  requirements  of  the  control  system.  Water  pres¬ 
sure  and  the  “Block”  and  “Reset”  switches  are  repre¬ 
sented  as  monitored  variables,  WaterPres,  Block,  and 
Reset;  safety  injection  as  a,  controlled  variable,  Safety 
Injection;  each  sensor  as  an  input;  and  the  hardware 
interface  between  the  control  system  software  and  the 
safety  injection  system  as  an  output..1 

A  mode  class  Pressure  and  a  term  Overridden 
help  make  the  specification  concise.  Pressure  con¬ 
tains  three  modes,  TooLow,  Permitted,  and  High.  A 
drop  in  water  pressure  below  a,  constant  Low  causes 
the  system  to  enter  mode  TooLow;  an  increase  in  pres¬ 
sure  above  a  larger  constant  Permit  causes  the  system 
to  enter  mode  High.  The  term  Overridden  is  true  if 
safety  injection  is  blocked,  false  otherwise.  An  exam¬ 
ple  of  a  condition  in  the  specification  is  “WaterPres 
<  Low” .  Two  examples  of  events  are  the  input  event 
@T(Block=0n)  (the  operator  turns  Block  from  Off  to 
On)  and  the  conditioned  event  @T(Block=0n)  WHEN 
WaterPres  <  Low  (the  operator  turns  Block  to  On 
when  water  pressure  is  below  Low). 

SCR  Notation.  The  A- 7  requirements  document 
[13]  introduced  a  special  tabular  notation  for  writing 
specifications.  Because  tables  are  easy  to  understand, 
the  tabular  notation  facilitates  industrial  application 
of  the  SCR  method.  Among  the  tables  in  SCR  speci¬ 
fications  are  condition  tables,  event  tables,  and  mode 
transition  tables.  Each  table  defines  a  function.2  A 
condition  table  describes  an  output  variable  or  a  term 
as  a  function  of  a  mode  and  a  condition,  an  event  ta¬ 
ble  describes  either  as  a  function  of  a  mode  and  an 
event.  A  mode  transition  table  describes  a  mode  as  a 
function  of  another  mode  and  an  event. 


1The  example  omits  the  SCR  brackets,  e.g.,  Anode*,  etc. 

2  Although  SCR  specifications  can  be  nondeterministie,  our 
initial  model  is  restricted  to  deterministic  systems. 


Old  Mode 

Event 

New  Mode 

TooLow 

@T(WaterPres  >  Low) 

Permitted 

Permitted 

@T(WaterPres  >  Permit) 

High 

Permitted 

@T(WaterPres  <  Low) 

TooLow 

High 

@T(WaterPres  <  Permit) 

Permitted 

Table  1:  Mode  Transition  Table  for  Pressure. 


Mode 

Events 

High 

False 

@T(Inmode) 

TooLow  or 

<a)T(Block=0n) 

@T(Inmode)  OR 

Permitted 

WHEN  Reset=0ff 

@T(Reset=0n) 

Overridden 

True 

False 

Table  2:  Event  Table  for  Overridden. 

While  condition  tables  define  total  functions,  event 
tables  and  mode  transition  tables  may  define  partial 
functions,  because  some  events  cannot  occur  when 
certain  conditions  are  true.  For  example,  in  the 
above  system,  the  event,  ®T(Pressure=High)  WHEN 
Pressure=TooLow,  cannot  occur,  because  starting 
from  TooLow,  the  system  can  only  enter  Permitted 
when  a  state  transition  occurs. 

Tables  1-3  are  part  of  REQ,  the  system  require¬ 
ments  specification  for  the  above  control  system.  Ta¬ 
ble  1  is  a  mode  transition  table  describing  the  mode 
class  Pressure  as  a  function  of  the  current  mode 
and  the  monitored  variable  WaterPres.  Table  2  is 
an  event  table  describing  the  term  Overridden  as  a 
function  of  Pressure,  Block,  and  Reset.  Table  3 
is  a  condition  table  describing  the  controlled  vari¬ 
able  Safety  Injectionas  a  function  of  Pressure  and 
Overridden.  Table  3  states,  “If  Pressure  is  High  or 
Permitted  or  if  Pressure  is  TooLow  and  Overridden 
is  true ,  then  Safety  Injection  is  Off;  if  Pressure 
is  TooLow  arid  Overridden  is  false ,  then  Safety 
Injection  is  On.”  The  notation  “@T(lnmode)”  in  a 
row  of  an  event  table  describes  system  entry  into  the 
mode  in  that  row;  for  example,  “@T(Inmode)”  in  the 
first  row  of  Table  2  means,  “If  the  system  enters  High, 
then  Overridden  becomes  false." 

3  Formal  Requirements  Model 

Our  requirements  model,  a  state  automaton  model, 
defines  sets  of  modes,  entity  names,  values,  arid 
types.  It  also  introduces  a  function  TY,  which  maps 
an  entity  to  its  legal  values;  in  the  sample  sys¬ 
tem,  TY(Overridden)={tr;«e,  false},  TY(Sensorl)= 
[14,2000],  TY(Safety  Inj ection)={0n,  Off},  and 
TY(Pressure)={High,  TooLow,  Permitted}.  The 
model  defines  system  state  in  terms  of  the  entities, 
a  condition  as  a  predicate  on  the  system  state,  and  an 
input  event  as  a  change  in  an  input  variable  that  trig¬ 
gers  a  new  system  state.  It  then  shows  how  a  set  of 
functions,  called  table  functions,  can  be  derived  from 
the  SCR  tables.  The  table  functions  are  used  to  define 
the  system  transform  T,  a  special  case  of  REQ  which 
maps  the  current  system  state  and  an  input  event  to  a 
new  system  state.  To  provide  a  formal  foundation  for 
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Mode 

Conditions 

High  or  Permitted 

True 

False 

TooLow 

Overridden 

NOT  Overridden 

Safety  Injection 

Off 

On 

Table  3:  Condition  Table  for  Safety  Injection. 


consistency  checking,  we  present  below  excerpts  from 
our  requirements  model  [10]. 

System  State.  We  assume  the  existence  of  the  fol¬ 
lowing  sets. 

•  MS  is  the  union  of  N  pairwise  disjoint  sets,  called 
mode  classes.  Each  member  of  a  mode  class  is  called 
a  mode. 

•  TS  is  a  union  of  data  types,  where  each  type  is  a 
nonempty  set  of  values. 

•  VS  is  a  set  of  entity  values  with  VS  =  MS  U  TS. 

•  RF  is  a  set  of  entity  names  r.  RF  is  partitioned  into 
four  subsets:  MR,  the  set  of  mode  class  names;  IR, 
the  set  of  input  variable  names;  GR,  the  set  of  term 
names;  and  OR,  the  set  of  output  variable  names.  For 
all  r  £  RF,  TY(r)  C  VS  is  the  type  of  entity  r. 

A  system  state  s  is  a  function  that  maps  each  entity 
name  r  in  RF  to  a  value.  More  precisely,  for  all  r  £ 
RF:  s(r)  =  v,  where  v  £  TY(r).  Thus,  by  assumption, 
in  any  state  s,  the  system  is  in  exactly  one  mode  from 
each  mode  class,  and  each  entity  has  a  unique  value. 

Conditions.  Conditions  are  defined  on  the  values  of 
entities  in  RF.  A  simple  condition  c  is  either  true, 
false,  or  a  logical  statement  c  =  r  ©  v,  where  r  £  RF 
is  an  entity  name,  ©  £  {=,  >,<,>,  <}  is  a  rela¬ 

tional  operator,  and  v  £  TY(r)  is  a  constant  value. 
A  condition  c  is  a  logical  statement  composed  of  sim¬ 
ple  conditions  connected  in  the  standard  way  by  the 
logical  connectives  A,  V,  and  NOT. 

Software  System.  A  software  system  E  is  a  4-tuple, 
E  =  ( Em ,  S,so,T),  where 

•  Em  is  a  set  of  input  events.  A  primitive  event  is 
denoted  as  @T(r  =  v),  where  r  is  an  entity  in  RF 
and  v  G  TY(r).  An  input  event  is  a  primitive  event 
@T(r  =  v),  where  r  G  IR  is  an  input  variable. 

•  S  is  the  set  of  possible  system  states. 

•  so  is  a  special  state  called  the  initial  state. 

•  T  is  the  system  transform,  i.e. ,  a  function  from  Em  x  S 
into  S. 

Events.  In  addition  to  denoting  primitive  events,  the 
“@T”  notation  also  denotes  basic  events  and  condi¬ 
tioned  events.  A  basic  event  e  is  denoted  as  e  = 
@T(c),  where  c  is  any  simple  condition.  A  simple  con¬ 
ditioned  event  e  is  denoted  as  e  =  @T(c)  WHEN  d, 
where  @T(c)  is  a  basic  event  and  d  is  a  simple  condi¬ 
tion  or  a  conjunction  of  simple  conditions.  Any  basic 


event  e  =  @T(c)  can  be  expressed  as  the  simple  con¬ 
ditioned  event  e  =  @T(c)  WHEN  true.  A  conditioned 
event  e  is  composed  of  simple  conditioned  events  con¬ 
nected  by  the  logical  connectors  A  and  V. 

We  define  the  logical  statement  represented  by 
a  simple  conditioned  event  as  @T(c)  WHEN  d  = 
NOT  c  A  d  A  d,  where  the  unprimed  and  primed  ver¬ 
sions  of  condition  c  denote  c  in  different  states.  We 
define  c' ,  where  c  =  r  ©  v,  as  c'  =  (r  ©  v)'  =  r'  ©  v. 
Based  on  these  definitions  and  the  standard  predicate 
calculus,  any  conditioned  event  can  be  expressed  as 
a  logical  statement.  Where  a  condition  is  evaluated 
in  a  single  state,  an  event  is  evaluated  in  two  states: 
unprimed  conditions  in  the  first  tor  old)  state,  primed 
conditions  in  the  second  (or  new)  state. 

Ordering  the  Entities.  To  compute  the  value  of  an 
entity  in  the  new  state,  the  transform  function  may 
use  the  values  of  entities  in  both  the  old  state  and  the 
new  state.  To  describe  the  entities  needed  in  the  new 
state,  we  associate  with  each  entity  r  a  subset  of  RF 
called  the  new  state  dependencies  set.  Given  entities 
r  and  f  in  RF ,  we  say  that  r  depends  directly  on  f  if 
f  is  in  r’s  new  state  dependencies  set.  The  “depends 
directly  on”  relation  imposes  a  partial  ordering  on  the 
set  RF .  Thus,  the  entities  in  RF  can  be  ordered  as  a 
sequence  R,  where  for  all  i  and  j  such  that  rj  and  rj 
belong  to  R,  rj  depends  directly  on  rj  implies  that  rj 
follows  rj  in  R  (that  is,  i  >  j). 

Table  Functions.  Each  SCR  table  describes  a  table 
function,  called  Fi,  for  some  entity  r;.  Table  func¬ 
tions  define  the  values  of  the  output  variables,  terms, 
and  mode  classes  in  SCR  requirements  specifications. 
Each  entity  defined  by  a  table  is  associated  with  ex¬ 
actly  one  mode  class,  Mj,  1  <  j  <  N.  To  represent 
the  relation  between  an  entity  and  a  mode  class,  we 
define  a  function  p,  where  p(i)  =  j  iff  entity  rj  is  asso¬ 
ciated  with  mode  class  Mj .  Using  this  notation, 
denotes  the  mode  class  associated  with  entity  r;. 

Presented  below  for  condition,  event,  and  mode 
transition  tables  is  a  typical  format,  a  representation 
of  the  information  in  each  table  as  a  relation  pi,  and  a 
set  of  properties  which  guarantee  that  pi  is  a  function. 
Given  pi,  we  can  derive  the  table  function  Fi. 

Condition  Tables.  Table  4  shows  a  typical  format 
for  a  condition  table  with  n  +  1  rows  and  p+ 1  columns. 
Each  condition  table  describes  an  output  variable  or 
term  rj  as  a  relation  pi  between  modes,  conditions,  and 
values,  i.e.,  p{  =  {(mj  ,cjtk,vk)  £  M^xQ  x  Tbfr,)}, 
where  C'i  is  a  set  of  conditions  defined  on  entities  in 
RF.  pi  has  the  following  four  properties: 

1.  The  nij  and  the  vk  are  unique. 

2.  U f=1mJ  =  Afjqq  (All  modes  are  included). 

3.  For  all  j:  Yvk=1c]tk  =  true  (Coverage:  The  disjunction 
of  the  conditions  in  each  row  of  the  table  is  true). 

4.  For  all  j,  k,l,  k  l :  cj,k  A  chi  =  false  (Disjointness: 

The  conjunction  of  the  conditions  in  each  row  of  the 
table  is  false). 
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Modes 

Conditions 

mi 

Cl,l 

Cl, 2 

Cl  ,p 

m2 

C2,l 

C  2,2 

to 

mn 

Cn,  1 

Cn,2 

Cn,p 

Ti 

Vl 

V2 

Vp 

Table  4:  Condition  Table — Typical  Format. 


Modes 

Events 

mi 

ei,i 

ei,2 

Cl  ,p 

m2 

e2,i 

e2,2 

C2  ,p 

mn 

Cn,  1 

Cn,  2 

Cn,p 

Ti 

Vi 

v2 

Vp 

Table  5:  Event  Table — Typical  Format. 


These  properties  guarantee  that  pi  is  a  function. 

To  make  explicit  entity  r2s  dependencies  on  other 
entities,  we  consider  an  alternate  form  7)  of  the  func¬ 
tion  pi.  To  define  Fi,  we  require  the  new  state  depen¬ 
dencies  set,  Df  =  {yiti,yit2,---,yi,m},  where  yi)X  is 
the  entity  name  for  the  associated  mode  class.  Based 
on  Df  and  pi ,  we  define  Fi  as 


Fi{yi. i , . . . ,  t/i>nl ) 


(  Vi  if  V"=1  («/;,!  =TOj  A  Cj,i) 
I  v2  if  V"=1  («/;,!  =TOj  A  Cj,2) 


l.  vp  if  V"=1  (y,,i  =m3  A  Cj,p). 

The  function  Fi  is  called  a  condition  table  function. 
The  four  properties  guarantee  that  Fi  is  total. 

Event  Tables.  Table  5  illustrates  a  typical  format  for 
an  event  table  with  n  +  1  rows  and  p+ 1  columns.  Each 
event  table  describes  an  output  variable  or  term  r;  as 
a  relation  pi  between  modes,  conditioned  events,  and 
values,  i.e.,  ^  =  {(rrij  ,ejtk,vk)  £  x  Et  x  TY(r;)}, 

where  E{  is  a  set  of  conditioned  events  defined  on  en¬ 
tities  in  RF.  pi  has  the  following  two  properties: 
f.  The  nij  and  the  vk  are  unique. 

2.  For  all  j,  k,l,  k  ^  l:  ehk  A  ej,i  =  false  (Determinism: 
The  conjunction  of  the  conditioned  events  in  each  row 
of  the  table  is  false). 

These  properties  and  assumptions  on  input  events 
guarantee  that  pi  is  a  function. 

As  with  condition  tables,  we  make  explicit  rfs  de¬ 
pendency  on  other  entities  by  defining  an  alternate 
form  Fi  of  the  function  pi.  To  define  Fi,  we  re¬ 
quire  both  the  new  state  dependencies  set  Df  and  an 
old  state  dependencies  set  Df  =  {*gi,  2,  •  •  • , 

where  Df  C  RF  contains  the  entities  needed  in  the 
old  state  to  compute  r;  and  aq-q  is  the  entity  name  for 
the  associated  mode  class.  Based  on  Df ,  Df,  and  pi, 
Fi  is  defined  by 


Old  Mode 

Event 

New  Mode 

771 1 

el,l 

ml,l 

el,2 

mi, 2 

eMi 

mi,kl 

mn 

en,l 

mn,i 

en,2 

mn,2 

en,kn 

mn,kn 

Table  6:  Mode  Transition  Table — Typical  Format. 

F,(xtp,  .  .  .  ,  Xifrni  ,  yi,  \ ,  .  .  .  ,  yi.n,  )  = 


'  v\  if  V"=1  (ii,i=mj  Aej,i) 
v2  if  V"=1  (aqq  =mj  A  eJi2) 

<  . 

.  vv  if  V"=1  (xi,\=mj  AeJ]P). 

The  function  Fi  is  called  an  event  table  function. 

Mode  Transition  Tables.  Table  6  shows  a  typical 
format  for  a  mode  transition  table.  A  mode  transi¬ 
tion  table  describes  an  entity  r;  that  names  a  mode 
class  M^qq .  The  table  describes  r;  as  a  relation  pi 
between  modes,  conditioned  events,  and  modes,  i.e. , 
Pi  =  {(mj,ejtk,mjtk)  £  M^qq  x  Et  x  M^qq},  where 
Ei  is  a  set  of  conditioned  events  defined  on  entities  in 
RF.  pi  has  the  following  four  properties: 

f.  The  nij  are  unique. 

2.  For  all  k  ^  k' ,  m]tk  ^  vnjki,  and  for  all  j  and  for  all 
k,  mj  7^  mJtk- 

3.  For  all  j,  k,  k' ,  k  ^  k'\  ehk  A  e]ty  =  false  (Determin¬ 
ism:  The  conjunction  of  the  conditioned  events  in 
each  row  of  the  table  is  false). 

4.  For  all  m  £  Afjyq,  there  exists  j  such  that  mj  =  m  or 
there  exist  j  and  k  such  that  m]tk  =  m  (Each  mode  in 
the  mode  class  is  in  either  pf  s  domain  or  its  image). 

These  properties  and  assumptions  on  input  events 
guarantee  that  pi  is  a  function.  It  is  easy  to  show 
that  a  mode  transition  table  with  the  format  shown 
in  Table  6  can  be  expressed  in  the  format  shown  for 
an  event  table.  Hence,  a  mode  transition  table  can  be 
expressed  as  an  event  table  function  T). 

Example.  To  illustrate  the  formal  model,  we  con¬ 
sider  the  condition  table  shown  in  Table  3  for  the  con¬ 
trolled  variable  Safety  Injection.  The  new  state 
dependencies  set  for  Safety  Injection  is  Df  = 
{Pressure,  Overridden},  where  i  is  the  index  of 
Safety  Injection  in  the  sequence  R.  Because  it  de¬ 
pends  directly  on  Pressure  and  Overridden,  Safety 
Injection  follows  them  in  R.  The  condition  table 
function  Fi  for  Safety  Injection  is  defined  by 

.Fi  (Pressure,  Overridden)  = 

{Off  if  Pressure  =  High  V  Pressure  =  Permitted  V 
(Pressure  =  TooLow  A  Overridden  =  true ) 

On  if  Pressure  =  TooLow  A  Overridden  =  false 
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4  Automated  Consistency  Checking 

Listed  below  are  examples  of  consistency  checks  de¬ 
rived  from  our  requirements  model. 

•  Proper  Syntax.  Each  component  of  the  spec¬ 
ification  has  proper  syntax.  For  example,  each 
condition  and  event  is  well-defined. 

•  Type  Correctness.  All  type  definitions  are  sat¬ 
isfied,  each  entity  is  assigned  a  type,  and  all  types 
are  defined. 

•  Completeness.  The  value  of  each  output  vari¬ 
able,  term,  and  mode  class  is  defined.  (Most 
variables  will  be  defined  by  tables,  but  standard 
mathematical  definitions  may  be  given  for  some 
output  variables  and  terms.) 

•  Reachability.  No  mode  is  unreachable. 

•  Initial  values.  Initial  values  are  defined  for  all 
mode  classes  and  input  variables  and  for  all  terms 
and  output  variables  not  defined  by  condition  ta¬ 
bles.  (Initial  values  are  not  required  for  entities 
defined  by  condition  tables,  since  they  can  be  de¬ 
rived  from  the  tables.) 

•  Consistency.  Each  condition  table,  event  table, 
and  mode  transition  table  satisfies  the  appropri¬ 
ate  properties  in  Section  3. 

•  Lack  of  Circularity.  There  are  no  circular  de¬ 
pendencies. 

Clearly,  some  checks  must  precede  others.  For  exam¬ 
ple,  checks  for  proper  syntax  must  precede  type  check¬ 
ing,  and  type  checking  should  precede  checking  that  a 
total  function  is  indeed  total. 

Examples.  Checking  the  consistency  of  Table  7,  a 
modification  of  the  condition  table  in  Table  3,  reveals 
four  errors.  The  second  row  violates  both  Coverage 
Overridden  V  Overridden  f  true)  and  Disjointness 
Overridden  A  Overridden  f  false).  The  third  row 
has  two  type  errors:  Safety  Injection  has  the  values 
Off  and  On,  not  False  and  True. 

Determinism,  the  second  property  required  of 
event  tables,  is  violated  if  events  in  two  differ¬ 
ent  columns,  say  e  and  e' ,  overlap,  i.e.,  e  A  e'  f 
false.  To  check  the  second  row  of  Table  8  (a 
variation  of  the  event  table  in  Table  2)  for  De¬ 
terminism,  the  expression,  [@T(Block=0n)  WHEN 
Reset=0ff]  A  [@T(Block=0n)  V  @T(Reset=0n)], 
is  evaluated.  This  expression  can  be  rewrit¬ 
ten  as  a  disjunction,  [@T(Block=0n)  WHEN 
Reset=0ff  A  @T(Block=0n)]  V  [@T(Block=0n) 
WHEN  Reset=0ff  A  @T(Reset=0n)].  Applying  the 
definition  of  event  evaluation  in  Section  3  to  the 
first  clause  of  the  disjunction,  we  have  [Block'  =0n 
A  Block=0f f  A  Reset=0f f]  A  [Block'  =0n  A 
Block=0ff].  This  implies  Block'  =0n  A  Block=0ff 
A  Reset=0ff .  Because  this  expression  does  not  equal 
false,  the  specified  behavior  is  nondeterministic.  Thus, 
if  in  TooLow  or  Permitted  mode  the  operator  turns 
Block  on  when  Reset  is  off,  the  system  may  nonde- 
terministically  change  Overridden  to  true  or  to  false. 


Mode 

Conditions 

High  or  Permitted 

True 

False 

TooLow 

Overridden 

Overridden 

Safety  Injection 

False 

True 

Table  7:  Modified  Table  for  Safety  Injection. 


Mode 

Events 

High 

False 

@T(Inmode) 

TooLow  or 

@T(Block=0n) 

@T(Block=0n)  OR 

Permitted 

WHEN  Reset  =  0ff 

@T(Reset  =  0n) 

Overridden 

True 

False 

Table  8:  Modified  Table  for  Overridden. 


Some  checks,  such  as  syntax  and  type  checking, 
are  easy.  More  complex  are  checks  that  evaluate 
expressions  containing  “Inmode” ,  depend  on  non¬ 
local  definitions  (other  than  type  information),  or 
require  deductive  reasoning.  Consider,  for  exam¬ 
ple,  checking  the  mode  table  in  Table  1  for  non¬ 
determinism.  Nondeterminism  can  occur  only  if 
events  in  the  second  and  third  rows  overlap,  i.e., 
if  @T(WaterPres>Permit)  A  @T(WaterPres<Low) 
is  true.  This  implies  WaterPres'  >  Permit  A 
WaterPres  f  Permit  A  WaterPres'  <  Low  A 
WaterPres  ft  Low.  By  assumptions  on  the  constants, 
Permit  >  Low.  This  and  WaterPres'  >  Permit  im¬ 
ply  WaterPres'  >  Low.  Hence,  the  expression  is  false 
and  the  defined  behavior  deterministic.  Because  in 
general  mechanical  evaluation  of  such  expressions  is 
hard,  the  tool  may  need  some  feedback  from  the  user 
to  complete  certain  checks. 

Prototype  Consistency  Checker.  A  prototype 
consistency  checker  that  performs  most  of  the  above 
checks  has  been  implemented.  It  is  coded  in  C+- 1- 
and  runs  on  X-Windows  with  Motif  widgets  to  sup¬ 
port  its  user  interface.  In  a  typical  session  with  the 
consistency  checker,  the  user  edits  a  specification  and 
then  runs  the  consistency  checker  to  test  for  selected 
properties.  The  tool  runs  the  selected  checks,  listing 
errors  that  it  finds.  The  user  may  select  one  of  the 
listed  errors.  In  response,  the  tool  displays  the  part  of 
the  specification  that  contains  the  error,  so  that  the 
user  can  make  needed  corrections. 

5  Applying  Consistency  Checks 

To  evaluate  the  utility  of  checking  requirements 
specifications  for  consistency,  we  conducted  two  ex¬ 
periments.  In  the  experiments,  we  used  early  versions 
of  the  consistency  checker  to  analyze  tables  in  a  revi¬ 
sion  [1]  of  the  software  requirements  document  for  the 
A-7’s  Operational  Flight  Program  (OFP).  The  new 
document  corrects  errors  in  the  original  [13]  and  uses 
Faulk’s  tabular  format  to  specify  mode  transitions  [6]. 

In  the  first  experiment,  our  tool  tested  all  36  condi¬ 
tion  tables  in  [1],  a  total  of  98  rows,  for  Coverage  and 
Disjointness.  The  tool  found  19  errors.  Seventeen  of 
these,  distributed  over  11  tables,  proved  to  be  legiti- 
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Error 

No. 

Explanation 

Slewing 

Variable 

9 

Behavior  for  3rd  value  of  variable 
Slewing  is  missing. 

GRTest 

4 

Some  tables  do  not  specify  be¬ 
havior  for  all  GRTest  submodes. 

Steering 

Phase 

3 

Early  document  used  3  values  to 
describe  steering  phases.  Revised 
document  uses  4  values,  but  some 
tables  have  not  been  updated. 

Application- 

Specific 

1 

(OTS  V  Range  to  RMax  <  0)  and 

NOT  (range  to  target  <  10  mi.) 
do  not  cover  the  domain. 

Table  9:  Errors  in  the  A- 7  condition  tables. 


mate  errors.  (Classifying  the  remaining  two  as  correct 
required  information  about  the  specification  that  our 
simple  tool  lacked.)  Table  9  describes  the  detected 
errors.  Interestingly,  all  are  Coverage  errors. 

In  a  second  experiment,  our  tool  checked  all  mode 
transition  tables  in  [1]  for  nondeterminism.  The  A- 7 
specification  contains  three  mode  classes  with  a  to¬ 
tal  of  46  different  modes  (18  modes  in  the  first  mode 
class,  7  modes  in  the  second,  and  21  modes  in  the 
third).  The  tool  checked  688  rows  and  found  33  non- 
deterministic  transitions.  Although  many  of  these  are 
undoubtedly  errors,  a  few  probably  are  not,  since  some 
detected  events  may  be  impossible.  (Recall  that  some 
events  cannot  occur  when  certain  conditions  are  true.) 
Reference  [11]  contains  examples  of  nondeterminism 
our  tool  detected  in  the  transition  table  for  the  OFP’s 
Alignment,  Navigation  and  Test  mode  class. 

Tool-based  vs.  Manual  Checks.  Prior  to  pub¬ 
lication,  the  revised  A- 7  requirements  document  was 
carefully  reviewed  by  two  teams,  one  made  up  of  NRL 
computer  scientists  (including  one  of  the  authors),  the 
other  composed  of  engineers  at  the  Naval  Air  Warfare 
Center  who  maintained  the  OFP.  As  noted  above,  our 
tools  detected  many  significant  errors  that  the  review¬ 
ers  missed. 

That  errors  were  detected  should  not  diminish  the 
credit  due  the  reviewers,  who  did  very  well  given 
the  large  volume  and  complexity  of  the  requirements 
data.  Tools,  such  as  those  we  developed,  can  comple¬ 
ment  the  efforts  of  software  developers.  Human  effort 
is  crucial  to  acquiring  the  requirements  information 
and  expressing  it  precisely.  Further,  after  errors  are 
detected  in  the  specification,  human  intervention  is 
needed  to  correct  them.  However,  once  the  developers 
have  a  reasonable  draft  of  the  requirements  specifica¬ 
tions,  software  tools  provide  a  quick,  effective  means  of 
checking  the  specification  for  properties,  such  as  those 
listed  in  Section  4.  Not  only  are  tools  more  effec¬ 
tive  than  people  for  checking  these  properties;  in  ad¬ 
dition,  they  can  reduce  significantly  a  labor-intensive 
task  that  humans  find  tedious  and  boring. 

Another  important  feature  of  our  tool  is  its  low  cost . 
In  the  Darlington  certification  effort,  which  cost  over 
$40M,  reviewers  checked  the  requirements  specifica¬ 
tions  for  application-independent  properties,  such  as 
Disjointness  and  Coverage.  In  addition,  they  searched 
for  discrepancies  between  the  requirements  specifica¬ 
tions  and  the  code  specifications  (the  third  class  of 


analysis  described  in  the  introduction).  A  tool  that 
compares  the  specifications  with  a  refinement  will  be 
more  complex  than  our  consistency  checker.  However, 
this  does  not  diminish  the  value  of  our  tool.  Parnas 
has  observed  that  the  “majority  of  the  theorems  that 
arose  in  the  documentation  and  inspection  of  the  Dar¬ 
lington  Nuclear  Plant  Shutdown  Systems”  were  simple 
properties  and  that  the  reviewers  analyzed  trivial  ta¬ 
bles  for  such  properties  in  documents  weighing  40  kg. 
[18].  Using  tools  to  do  such  analyses  should  cost  far 
less  than  using  people. 

Related  Work.  In  a  related  effort,  Atlee  and  Gan¬ 
non  use  model  checking  to  analyze  SCR  requirements 
specifications  [2].  Unlike  our  tool,  theirs  evaluates 
application-specific  properties.  Further,  where  our 
consistency  checker  tests  all  tables  and  definitions  in 
an  SCR  specification  automatically,  their  tool  analyzes 
the  mode  transition  tables  only,  extended  by  hand  to 
incorporate  the  needed  variable  definitions. 

In  other  related  work,  Parnas  describes  ten  small 
theorems  related  to  his  tabular  notation  (similar  to 
other  SCR  notation)  and  challenges  the  developers  of 
automated  proof  systems  to  prove  the  theorems  [18]. 
Two  of  the  theorems,  the  Domain  Coverage  Theorem 
and  the  Disjoint  Domains  Theorem,  are  slight  vari¬ 
ations  of  our  Coverage  and  Disjointness  properties. 
SRI  researchers  accepted  Parnas’  challenge.  In  a  re¬ 
cent  paper  [20],  they  describe  the  mechanical  proof  of 
nine  of  Parnas’  theorems  using  the  “tcc-strategy”  (tec’s 
are  type-correctness  conditions)  of  SRI’s  proof  system 
PVS  [16].  That  PVS  can  prove  such  theorems  easily  is 
not  too  surprising,  since  the  proofs  require  very  simple 
logic.  What  is  noteworthy  about  the  PVS  experiment 
is  that  the  theorems  were  proven  automatically. 

A  recent  experiment  [19]  compares  the  effectiveness 
of  three  different  inspection  methods  for  detecting  er¬ 
rors  in  SCR  requirements  specifications.  Many  of  the 
errors  of  interest  in  the  experiment  can  be  automati¬ 
cally  detected  by  our  consistency  checker.  Using  a  tool 
like  ours  in  conjunction  with  inspection  would  proba¬ 
bly  detect  more  errors  than  either  alone. 

6  Software  Development  Process 

We  envision  the  following  process  for  developing  re¬ 
quirements  specifications.  First,  the  developer  uses 
the  SCR  notation  to  specify  the  requirements.  Next, 
he  uses  an  automated  consistency  checker  to  test  for 
syntax  and  type  correctness,  coverage,  determinism, 
and  other  application-independent  properties.  The 
next  step  is  to  symbolically  execute  the  specification, 
using  a  simulator,  to  ensure  that  it  captures  the  de¬ 
veloper’s  intent;  the  simulator  can  be  run  either  man¬ 
ually,  or  automatically  using  an  input  script  (see,  e.g., 

[3])- 

In  the  later  stages  of  requirements,  the  developer 
uses  mechanical  support  to  analyze  the  specification 
for  application  properties.  Initially,  he  extracts  a  small 
subset  with  fixed  parameters  and  only  a  few  states 
from  the  specification  and  uses  a  model  checker.  This 
may  be  repeated,  each  time  with  a  different  or  larger 
subset.  Once  he  has  sufficient  confidence  in  the  speci¬ 
fication,  the  developer  may  use  a  deductive  proof  sys¬ 
tem  to  verify  safety-critical  components. 
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7  Concluding  Remarks 

Based  on  our  experience  with  automated  consis¬ 
tency  checking  to  date,  we  have  four  conclusions: 

•  Tools  for  consistency  checking  can  be  highly  effec¬ 
tive  for  detecting  errors  in  requirements  specifica¬ 
tions.  Not  only  can  such  tools  find  errors  people  miss; 
they  can  liberate  people  from  the  unpleasant  task  of 
checking  specifications  for  consistency. 

•  Properly  designed  tools  are  significantly  more  cost- 
effective  than  people  for  consistency  checking. 

•  Computer-based  analysis  requires  an  explicit  formal 
semantics,  such  as  that  provided  by  our  requirements 
model.  This  semantics  provides  the  basis  for  algo¬ 
rithms  that  do  the  analysis. 

•  The  formal  methods  on  which  our  tools  are  based 
scale  up.  They  detected  a  significant  number  of  errors 
in  a  medium-size  real-world  specification. 

Currently,  we  are  building  a  more  complete  version 
of  the  toolset,  which  includes  the  consistency  checker, 
a  specification  editor  and  a  simulator.  We  also  plan 
a  verifier  that  checks  for  application  properties.  An 
option  being  considered  is  to  link  the  toolset  with  a 
mechanical  proof  system  to  support  both  automated 
consistency  checking  and  computer-assisted  verifica¬ 
tion.  This  would  relieve  us  of  the  difficult  and  error- 
prone  task  of  encoding  the  logic  ourselves. 

We  expect  our  requirements  model  to  provide  a 
solid  foundation  for  a  suite  of  analysis  tools.  We  also 
expect  the  process  outlined  above,  which  uses  for¬ 
mal  notation  to  specify  requirements  and  computer- 
supported  formal  analysis  to  detect  errors,  to  produce 
high  quality  requirements  specifications.  Such  speci¬ 
fications  should  significantly  reduce  software  develop¬ 
ment  costs. 
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